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INTRODUCTION 

The Simulation Computer System (SCS) is the computer hardware, software^ 
and workstations that will support the Payload Training Complex (PTC) at MSFC. 

PTC will train the Space Station payload specialists and mission specialists to operat 
the wide variety of experiments that will be on-board the Freedom Space Station 

This Simulation Computer System (SCS) Study Issues Report s j J ^ r,zes f 
analysis and study done as Task 1- Identify and Analyze SCS Study Issues of the 
SCS V Study contract . This work was performed over the first three months of the SCS 

Study, which began in August of 1988. 

First, issues were identified from all sources. These included the NASA SOW, 
the TRW proposal, and working groups which focused the experience N £SA a 
he contractor team performing the study - TRW, Essex, and Grumman. The fmal haft is 
shown in Figure Issues 1, and is organized into training related issues and I SCS 
associated development issues. To begin the analysis of the issues, a is 
functions for which the SCS could be used was created, i.e. when the computer is 
turned on what will it be doing. Analysis was continued by creating an operational 
unctions matrix of SCS users vs. SCS functions (Figure Issues 2) to insure al the 
functions considered were valid, and to aid in identification of users as the analysis 
progressed. The functions will form the basis for the requirements, which are cu y 
being developed under Task 3 of the SCS Study. 

To ensure that all relevant issues are identified, and as an a 'd Jo beginning 
analysis of all the issues, a matrix of the issues vs. functions (Figure 'ssues 3a &3b) 
was created. Filling in this matrix gave the study team an indication of the breadth - 
issues that affected many functions - and the depth - issues that had a large effect , but 
on only a few functions- of all the issues to be further analyzed. 

A different and important view and analysis of the ^ues was 
creatinq the cost factor vs. SCS issue matrix (Figure Issues 4a & 4b). This matrix 
shows which issues have big, medium, or small potential impact on the 
and operating the SCS system. Thus, this matrix is meant as a guide to emphasis and 

detail of analysis for each issue. 

An issues form was created to capture the details of the analysis being 
nerformed and this form evolved as the analysis proceeded. The final version of this 
tor^ITshown as Figure Issues 5. Following this are the completed forms for each of 
the issues The data on these forms is the result of the matrices above, study, tb °J9 bt - 
grlphte analysis, and numerous SCS working group meetings to d.scuss and lay the 

SCS ground rules and assumptions. 

The assumptions listed on the issue forms are duplicated in the issues 
appendix after the completed forms so that all SCS assumptions can be easily 
accessed and assessed. 
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Issues requiring further analysis, as indicated on the forrn under 
recommendations, needier analysis to aid the s t u dy team i n wnl mg a good I tot cut 
requirement. Many of the issues will be further analyzed as part of SCS Study Task 
- Develop SCS Conceptual Designs. 

MSFC is responsible for approving this SCS Issues Retort. I-aDDra^^ 

S SSES& 

comments or additions that are relevant and important are solicited. 
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Training Related Issues 
Further 

Study? Issue Number & Titlfi 

Yes T-1. Scope of Payload Crew Training in PTC 

No T-2 Scope of Ground Operations Personnel Training in PTC 

Yes T-3. Scope of OMS Training in PTC . 

Yes T-4. Scope of Integrated Core Subsystem Training in PTC 

No T-5. Fidelity of SS Payload Subsystems Simulations 

m 0 T-6. Fidelity of SS Experiment Simulations 

No T*7. Fidelity of SS Experiment to System Interfaces 

No T-8. Fidelity of SS Internal Data Flows Simulations 

No T-9. Fidelity of SS Downlink and Uplink 

Yes T-1 0. Fidelity of Element Control Workstation (ECVyS) 

No T-1 1 . Support for Training Multiple Missio ^ s u ^^ urta J®J^ s I. nt . r _ 

No T-1 2 Support for Integrated Simulations with Other NASA Centers 

Yes T-1 3. Support for Interoperable (Remote Executions) Simulations 

No T-1 4 Requirements for SCS Interface with External Facilities 

£ £1! lor Rate Requirements 

No T-1 7. Requirements for High Rate Data Requirements 

No T-1 8. Requirements for Virtuallnstruments , rnn(rn . 

No T-1 9. Requirements for Simplified Simulator Operations Setup and Control 

Yes T-20. Support for Onboard Training 

Associated Development Issues 


Issue Nu mber & Title 


Further 
Study? 

Nn A-1 Utilization of SSE Capabilities 

So A-2. Techniques for Integrating and Maintaining Pi-Provided Simulators 

Yoc a- 3 Techniques for Supporting late changes to simulators 

No A-4. Allowing Software Transportability between SCS and other centers 

Yes A-5. Techniques for Integrating Flight Hardware/Software with SCS 

Yes a- 6. Flexibility for Allowing Advanced Technology Insertion 

yoc A-7. Implications of Simulation Development Cycle 

Yes A- 8 Sizing Growth Potential in Capability/Capacity 

No A-9l Defining Telemetry Data Format and Calibration 

Yes A-10. Fidelity of DMS Interface 

Yes A-1 1 . Definition of “No single point of failure” 

No A-1 2. Requirements for Interfaces with SOAN and SSlb 

No A-1 3. Requirements for Configuration Management of Simulation Software 

Yes A-1 4. Definition of GSE-Provided Services 

Figure Ussues 1. List of SCS Study Issues 
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Figure Tta®s 4a. Cost Factors vs. Training Issues 
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Figure Hssrawss 4 Mb. Cost Factors vs. Development Issues 
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SCS Issue Identification 

Issue Title: 

Issue No: Report Version: 

Scope of Potential Requirem ent 

Assumptions 

Brief summary and rationale 
Training Viewpoint 

SCS Development Viewpoint 

Operations Evaluations ViewDQi nl 

Recommendations 

o No additional study required. Derived SCS Requirements and Implications on SCS 
Design: 

o Additional study required. Define study subjects and type of required analysis, 
e.g.; trades, simulations, projections. 

Related Issues; 

Open Issues/Notes 


Figure issues 5. Blank SCS Issues Form 
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TRAINING ISSUES 
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SCS Issue Identification 

Issue Title: Scope of Payload Crew Training in PTC 

Issue No: T-1 Report Version: 4 


Scope of Potential Require ment 

The scope of payload crew training in the PTC could range from simple single 
experiment operations training in a nominal operations scenario to full c ° ns ° lt ^® 
experiment operations training responsibility including orientation, 
experiment training for nominal and malfunctions scenarios, and full consolidated 
experiment liainin^ with all experiments from a 

oDeratina as a consolidated payload with all elements of the SS. The scope or me 
traininq responsibility of the PTC and the resulting fidelity of experiment simulators and 
SS payload subsystem interfaces will be the major driver on the SCS requirements. 

Assumptions 

1. Primary responsibility of the PTC is to provide payload operations training 
including both nominal and contingency operations for flight and ground person e . 

2 Pavload operations training will include experiment training, payload unique 
operations support systems training , and payload unique subsystems training. 

3 The PTC/SCS will support all manned payload training for all payloads, 
including US Lab, Attached Payloads, ESA, and JEM. 

Brief Summary and Rationale 

Irainma ViewpQinl 

The PTC will provide experiment operations training to the flight payload crew 
beginning 12 months prior to launch. Training will consist of individual experiment 
operations and consolidated payload operations (at the payload level). Training at the 
PTC is expected to last about 9 months and will include three major phases 
Individual experiment operations, experiment operations consolidated wrth payload 
subsystems, and finally consolidated experiment training in the Element Trainers 

environment. 

There will be 4 crew/increment and 1/2 of the crew will be exchanged each 
flight Thus the PTC will not only have the responsibility of training on payload 
operations for a particular flight but also must provide experiment operations training 

for the preceding P and the following increment confi ? ura,l0ns th ^®"^'T 0 ^ C o^e o 
configuration there will be 6 crew participating in training on .that. conjigurati or '■ ° 

the primary objectives of the PTC will be to support team building in payload 
operations^ allow the crew to work efficiently as a team to accomplish consolidated 

payload operations. 
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The Davload training process will follow a building block approach in which the 

SHr{?f: a ?o 

Can5re U — JtonsTnS the ttomTn"? w5*s«^CWS)7he Life 
iencTand M“nce workstations, the Materials Processing and L,fe Sciences 
Gloveboxes, and the Command and Control workstations. 

SCS Development Viewpoi nt 

The scope of payload crew training will be one of the J^ r 9 est ^ rivers .'^J®^ t f 
i h nn tho ope The associated load for development of the software, integration, 
el? maintenance In l lon^gu lho? management will also be quite large, probably 
IlSW S Thl Toad for training. We need to have a good set of requirements and a 
good understanding of all of this to be able to properly size and design the SCS. 

Operations Fvaluations Viewpoint 

RCS caoabilities for the support of full consolidated experiment operations 
treinino shouW provfdeThe required functions for the prototyping, development 
evaluation and verification of flight crew procedures. The simulations of the Pey'oad 
cuDDort sv’stems (e q PMMS, Lab Support Equipment) and their interactions with the 
expehmemsllouldbe simulated to a Tgh level of Wo prejen, .the .use of aality- 
roiotoH workarounds in procedure verification. The SCS wilt support ies>imy ut 
maintenance procedures for only those experiments which provide flight equivalent 

hardware to the PTC. 

Recomme ndations 

o Additional study required. Additional analysis of typical design reference 
navinarte must be Derformed to determine maximum loading on the SCS at any given 
hnrn°tTsupoort payload training. Analysis will include classifying SS payloads into 
three levelTof simulator complexity and then determining CPU sizing requirements 
Kd on ex?lriment simulators that have beer , developed for the i Space ab t ammg 
program in the PCTC. Additional study will determine the SCS load required to 

support training for Attached Payloads. 

Open Issues/Notes 



TRW-SCS-89-T1 


Issuas 13 


SCS Issue Identification 

Issue Title: Scope of Ground Operations Personnel Training in PTC 

Issue No: T-2 Report Version: 4 


Scope of Potential Requirement 

The scope of PTC support to ground operations personnel traininQ^ldrange 
from limited support to ground support operations training for selected POIC console 
pos^ionfinvolv P e P d in direct commanding to indi vidual 

simulation of all POIC functions including data transformation, etc. P ^C support to 

ground operations training could be limited to just operations r tr ®' n '^ _ f °' . ^ te? ulir 
positions or could also include training responsibility for personnel in the Use 
Operation Facilities (UOFs), the Discipline Operations Centers (DOCs, the Regiona 
Operations Centers (ROCs), and the Engineering Support Center (ESC). 

Assumptions 

4. ESC training is assumed to not be a responsibility of the PTC. No unique 
interface between the ESC and the SCS is required, nor w.l simulators 

require any unique capabilities related to ESC training. The only support of the SCS 
uTeSC training will be via the POIC during consolidated and/or integrated simulations. 

5 Any PTC interfaces to UOFs, DOCs, or ROCs wil! be through the POIC. There 
will not beany direct data interfaces from the PTC to the UOFs, DOCs, or ROCs. 

6 The POIC can support the processing of real time or simulated d ^a streams 
simultaneously. This means the POIC can support training using simulated data from 
the PTC simultaneous with on going real time operations. 

Brief Summary and Rationale 

Training Viewpoint 

The first utilization of the PTC will be to train Payload Operations Int egration 
Center (POIC) controllers. The PTC must provide payload training for the US Lab 

Pressurized Logistics, Node modules, and attached P a y |oads n ^he PCTC^has 
POIC cadre trainino will extend beyond the traditional support that the 
proved » POCC talrtng in integrated simulations^ PTC will provide .the Mnng 
for the POIC ground support staff both before the POIC is available for use and after it 
becomes full? operational and occupied. Specific POIC consote trainers wd be 
necessary at the PTC. These consoles could then be fed payload data via payload 
simulations in the SCS host environment. 
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The sDecific training load that POIC personnel will place on the PTC will 
operattons TteTJt £?n 

th P e relative amount of payload operations training needed by each P 0Sltl ?T! v f h ^ 

training must also be considered in the SCS requirements 

For POIC console training in the PTC, approximately 7 POIC consoles will be 

SsiSssss 

monitoring, special computation execution, and display support o 
may be required at the PTC. 

SCS Development Viewpoint 

The scope of ground operations personnel training will be a s .'9 n |^ ar ]! 
qps Jd Be cvcle vs development costs will be a factor m the final SCS 

delta in effort above that required to build the simulators for issue T . 

Operations Evaluations Viewpoint 

SCS caoabilities for the support of POIC console training should provide the 

ssaysssaa x“» r stilus" 

notations and workarounds must be employed to compensate. 

Recomm endations 

payloads from the POIC, and downlink of all payload bus data packets. 


Related Issues; T-14 
Open Issues/Notes 
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SCS Issue Identification 
Issue Title: Scope of OMS Training in PTC 

Issue No: T-3 Report Version: 3 


Scope of Potential Require ment 

Operations Management System (OMS) training 
nn interface between the payload simulators to a full interface with OMS trainers at 
JSC via an Operations Management Application (OMA) node On the mimmurri len o 
the OMS trainina level payload operations training at the PTC could have no 
relationship to OMS. On the maximum end, all payload training at the PTC cou 
conducted in the OMS environment. 


Assumptions 

7 The OMS software functions will be provided as part of the DMS Kits. Therefore 
no special simulator development will be required for OMS training. 

Brief Summary and Rationale 


Training Viewpoi nt 

The Operations Management System will include an Operations Management 
Application (OMA) node for on-board operations and an Operations Management 
rrniind Application (OMGA) node to support ground operations. Under each of these 
systems there will potentially be unique Payload Management System functions^ a 
will relate to the experiment operations. The pnmary training responsibility of the PTC 
will be on unique payload management functions relating to the OMS. 

SCS Development Viewpoint 

Even with our assumption that OMS is provided, there wiH be some interface 
and integration effort required of the development team. However, the use of WP02 
provided^ OMS and OMGA simulation or the real flight software seems to be the be 
way to go, rather than have the PTC develop simulations for these. 

Operations Evaluations Viewpoi nt 

Crew and around procedures can be expected to be heavily oriented toward 
the use of payload OMA functions for payload operations. A high fidelity smulation (or 
the use of actual payload OMA flight software) will be required to support procedure 
development and verification. 
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Rft^ mmendatiQns 

o Additional study required. The loading impact to the SCS to support OMS 
training must be determined 


Open Issues/Notes 

The unique payload management functions that will l be involved ir i the . OMS 
must be determined and the potential load that this implies to the SCS must be 

determined. 
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SCS Issue Identification 

Issue Title: Scope of Integrated Core Subsystem Training in PTC 

Issue No: T-4 Report Version: 3 


Scope nf Potential Requirement 

The scope of the PTC support to integrated core subsystem training could range 
from experiment operations training which is totally independent of SS < sore 
subsystem statuses to a fully integrated simulation environment ,n which there is a two 
way interface between experiment simulators and the SS core subsystems Sl ™tet 
either within the PTC or in the SSTF. With this two way interface the experiment 
simulators would receive subsystem status data and be responsive to these inputs and 
would provide experiment status back to the subsystem simulators which wo 
represent the experiment load on the subsystems. These subsystem S'mulato^ would 
be responsive to the experiment load to provide realistic experiment load reactions to 

the subsystem controllers. 


Assumptions 

8 The PTC will not be responsible for any subsystems training. However, the PTC 
will utilize minimum subsystem interfaces as necessary to support payload training. 

9. All software subsystem simulators utilized in the PTC will be provided by work 
package contractors via the SSE. Modifications of these will be required. 

Brief Summary and Rationale 


Training Viewpoint 

In the Spacelab training environment, payload operations training has been 
conducted with minimal interaction between the experiment and subsystems 
simulators. Spacelab experiment simulators have utilized simple discrete status data 
from subsystem simulators but have not provided any load data back into ' the 
subsystem simulators that would be reflected in data that is provided to the subsystem 
controllers. This has proved to be adequate for crew and payload cadre operations 
training but may not be adequate for subsystem training. The r . es P on f lblll ! y ° f / n h t ® 
to support core subsystem training must be determined and the level of ,nt0 dace 
fidelity between the core subsystems and the experiment simulators that is required to 
provide adequate experiment operations training must be defined. 

SCS Development Viewpoint 

Since we are assuming no responsibility for subsystem training, there will be no 
SCS development load for subsystem training. However, there will be SCS 
requirements for interfaces to subsystem simulations, and there will be a load for 
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integration. If simulations run on the SCS host, this must be included in the sizing and 
timing. 

Operations Evaluations ViewPQinl 

The use of subsystem simulations to support the payload simulators will provide 
adequate capabilities for the development and verification of purely expenment 
^Derations crew/around procedures. The level of influence of the subsystems on the 
procedures° musTb^ evaluated. For example, if a part of a payloadachva,,on 
nrocedure reauires the payload operator to access the LAB power system then the 
procedure cannot be verified in the PTC without a simulation of the LAB power system 
in excess of what is required to interface with the payload simulations. The evaluation 
of prototype experiments or new technologies may also require PPy sl “' f'Tjnahnike 
certain core subsystems such as thermal and power to provide needed fhght-like 

services. 

Recommendations 

o Additional study required: Additional analysis is nee ? ed /°J®!®^ n n e p 
necessary level of interface between subsystems and experiments. Information needs 
to be obtained from the SSTF developer (Mitre) about anticipated interface between 
the subsystem and payload simulators. We also need to determine the execution rate 
of the subsystem simulators, specifically will some simulators have to execute at a rate 

greater than 1 Hz. 

Open Issues/Notes 

Reference Draft 1 of the OP14 Plan (D683- 1 01 35-1 ); "A preliminary survey 
indicates none of the common subsystems are required to support payload 
simulations interfaces". 
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SCS Issue Identification 

Issue Title: Fidelity of SS Payload Subsystem Simulators 

Issue No: T-5 Report Version: 2 


Scope of Potential Requirement 

The scope of Space Station subsystem simulators can range from very 
simplistic low fidelity simulators that only provide discrete interface status to 
experiment simulators to fully functional subsystem simulators which provide two way 
interface capability to experiment simulators with detail subsystem data such as 
Electrical Power Distribution System voltage levels, cooling system temperatures, etc. 
These higher fidelity subsystem simulators would provide subsystem control capability 
and also reflect experiment status inputs into the subsystem data parameters. The 
number and type of subsystems to be simulated is also a driver of the SCS 
requirements. The subsystems associated with the US Lab, Pressurized Logistics, 
and Node Modules must be included. Additionally, the PTC support to the 
international payload modules must be considered. 

Assumptions 

2. Payload operations training will include experiment training, payload unique 
operations support systems training , and payload unique subsystems training. 

4 ESC training is assumed to not be a responsibility of the PTC. No unique 
interface between the ESC and the SCS is required, nor will the SCS simulators 
require any unique capabilities related to ESC training. The only support of the SCS 
to ESC training will be via the POIC during consolidated and/or integrated simulations. 

Brief Summary and Rationale 

Training Viewpoint 

In the Spacelab program, relatively simple subsystem simulators have been 
utilized to support payload operations training. The major thrust of Spacelab PCTC 
training has been on experiment operations, and systems training has not been a 
major function. Spacelab systems training has been a JSC responsibility rather than 
the responsibility of MSFC. This will also be the case for Space Station training. 
Systems simulators will be developed for the WP01 elements under the Software 
Support Environment (SSE) for the purpose of testing flight software development. 
These software testing simulators may be simple command/response simulators that 
only serve to provide test scenarios for the software interfaces. However, it may be just 
as practical to develop dynamic systems simulators to test the flight software because 
the software interface to the systems may be so complex. If this is the case, then these 
simulators could be migrated into the PTC and modified for trainer use. SS payload 
operations will be largely built around various SS workstations such as the Element 
Control Workstation (ECWS), Life Sciences and Maintenance workstations, the 
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Mfltprials Processinq and Life Sciences Gloveboxes, and the Command and Control 
workstations. The SCS design must account for the anticipated utilization o 

subsystem simulators. 

The OP14 Plan reference identifies the US Lab subsystems that will be required 
to interface to payload simulations in the PTC. These subsystems inc u e. 

Vacuum Vent System 

Acceleration System 

General Lab Support Facility 

Preservation and Storage System 

Maintenance Workstation/Lab Sciences workbench 

Mass Energy Analysis (MEA) Subsystem 

Process Materials Management Subsystem (PMMS) 

In addition, elements of the Animal Specimen Transport System (ASTS), and 
the Inventory Management System may be required to support payload training. 

scs Development Viewpo int 

If most of the payload subsystems were done in software, this would be a factor 
in the SCS However, since current thinking indicates that most of these 
simulations that will be done with physical things (not software) there is not much affect 
on ^ SCS However, some of these, like the current PCTC instrument pointing 
system simulation may 'be done in software. The fidelity and size of these software 
sfmulations would then have a significant effect on SCS loading and size. 


Operations Evaluations Viewpo int 

The operation of the payload support subsystems will be an integral part of 
overall payload operations. Therefore, it should be expected that many crew 
Drocedures will involve the use of these support systems either in a stand-alone mode 
or integrated with the operation of the individual experiments. The simulations of the 
LAB payload support subsystems must be adequate to support P ro p®^ re . v ^ ri /' ca ]! on ' 
The requirement for payload support subsystems simulators of a higher fidehty than 
those available from the SSE is therefore indicated to support integrated operations 
with the individual experiments. The evaluation of payload data management and 
operations techniques also supports this requirement since the payload support 
subsystems are a key interface for many LAB expenments. 

Rftrnmmendations 

o No additional study required. The PTC SCS must be capable of executing 
simulators developed in the SSE. Payload subsystems simulators that are developed 
fortesting flight software development may be modified to support training in the PTC. 


Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Fidelity of SS Experiment Simulators 

Issue No: T-6 Report Version: 2 

Scope of Potential ReQUir emfifll 

The scod6 of fidelity of experiment simulators can range from total software 
emulate all command and data in, ® r ^ ,l °" s °/ notem^^'^perimen^mallunctions. 

Ex^rimenf simulation can arrange trom^imuLting only housekeeping/operations 
data to providing simulation of the experiment science data. 

Assumptions 

equivalent hardware and software when it is available. 

Brief Summary and Rationale 
Training Viewpoint 

in order to provide adequate payload operations trainmg to the flight crew, the 
scs naveiooment Viewpo int 

The method used to t e h |^ e s qu '^t 'uleot rnghT^Tu^alent ha^dwa^e and 

Sn «2 SCS. 
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Operations Evaluations Viewpoint 


Experiment simulators of an appropriate fidelity to fully support training should 
be adequate for all operations evaluation functions. Flight equivalent experiment 
hardware will be required for testing of maintenance procedures. 


Recommendations 

o No additional study required. Fidelity of SS experiment simulators will be 
consistent with the simulators that have been developed for Spacelab. Analysis of t 
SS design reference mission will determine SCS loading requirements. 

Related Issues; A-5 
Open Issue/Notes 
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SCS Issue Identification 

Issue Title: Fidelity of SS Experiment/Subsystem Simulator Interfaces 

Issue No: T-7 Report Version: 4 


Scope of Potential Requirem ent 

The scope of the interface between experiment and subsystem simulators can 
range irom^or HrSted system/experiment interface to a fully functional two way 
interface between the subsystem trainers and the experiment simulators. 

Assumptions 

9 All software subsystem simulators utilized in the PTC will be provided by work 
package contractors via the SSE. Modifications of these will be required. 

Brief Summary and Ration ale 
Training Viewpoint 

The additional emphasis of the PTC to support training for P°'C and SSCC 
indicates a need for greater fidelity of interfaces between experiment and subsystem 
simulators. Since the MSFC primary training responsibility is to provide 
training, the simulation of the workstation interfaces and the experiment/system 
interfaces will be of primary importance. 

SCS Development Viewpoint 

This will have an impact on conceptual and detailed design, but the 
requirements for interface are relatively straight forward. Subsystem mterlace support 
may be required for high fidelity subsystem simulators developed in the 
theexperiments to respond to subsystem status data and to provide load data that can 
be reflected in the subsystem simulators in the SSTF. An Interface Control Document 
will be developed to define the level of interface between the subsystem simulators 
and the payload simulators. 

Operations Evaluations Viewpoin t 

A key aspect of this issue which requires further evaluation is the amount of 
interaction with the SS systems by the payload operators in the course of payload 
operations. If payload operations procedures include significant interactions with Jhe 
systems, then these systems and their interfaces to the experiments must be simulated 
to a high degree of fidelity. Additionally, high fidelity subsystem simulator interface^ 
must be provided to support the evaluation of prototype experiments or support 
equipment which might interface with the systems. 
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Recommendations 


o No additional study required. This is not a significant issue from the standpoint 
of the SCS requirements although it may be an issue from the standpoint of the 
manpower required to develop and implement experiment simulator requirements. 


Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Fidelity of SS Experiment Simulator Internal Data Flows 

Issue No: T-8 Report Version: 2 


Scope of Potential Requirement 

Data flow within the PTC between experiments could range from an internal 
sharing of data within the host system memory to a total emulation of actual data flow 
services between the experiment and the host data management system. 

Assumptions 

12. The PTC will utilize DMS Kits that are provided by JSC/WP02. 

Brief Summary and Rationale 
Training Viewpoint 

From a payload operations training viewpoint a simulation of the internal data 
flows may not be necessary for crew payload operations training as long as the data is 
available to the trainee in the same format as it would be in the actual operations 
environment. However, simulation or emulation of certain aspects of the data flow 
process may be necessary in order to provide training on anomalies or malfunctions 
relating to the data flow process. For example, for training on experiment operations it 
would not be necessary to simulate the communications protocol required between 
the actual SS data management system and the experiment as long as the data was 
available to the trainee in the same format and access mode as he would have in flight 
operations environment. However, if the training objective was specific to the data 
transfer function between the host data management system and the experiments then 
it would be necessary to simulate the actual protocols and different malfunction 
scenarios that might result from problems within either the experiment or the data 
management system. 

SCS Development Viewpoint 

From a development standpoint, the fidelity of internal data flows is important to 
determine how experiment data should be simulated and passed to the host system, 
and fidelity will have an effect on code size, and thus on loading. Data could be 
simulated in engineering units eliminating the need for data formatting software in the 
host system, but this might create additional requirements for generating data streams 
to the POIC consoles if they expect the data in a different format than it is made 
available to the on-board crew. 
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Since DMS Kits and some amount of flight software are assumed to be present 
in the SCS the required interfaces will be present for the evaluation of different 
pay to^tfdata management and operations techniques. The DMS Kits and the ability 
to mn Davload software will also support the evaluation of prototype experiments or 
suDDort equipment For procedure development and verification, the simulator internal 
Sfffew are noi considered to be important as long as the simulators produce 

accurate command responses. 


o No additional study required. The utilization of DMS kits or equivalent subsystem 
simulators provided by JSC requires that internal data flows between the experiments 
and the host DMS will be the equivalent of flight interfaces. 



We need to determine how many modules and/or workstations the PTC SCS must 
support. 
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SCS Issue Identification 

Issue Title: Fidelity of SS Experiment Downlink Data and Uplink 

Command Capability 

Issue No: T-9 Report Version: 1 

Scope of Potential Requirement 

The scope of this issue can range from no downlink telemetry or command 
uplink capability from/to simulators in the PTC to a full systems simulation of the 
telemetry/command system. Telemetry data simulation could further range from a 
static data stream generation to a fully dynamic simulation of all parameters in a data 
stream. In addition, simulation could be limited to certain data streams such as the 
Spacelab ECIO data stream without providing simulation of dedicated experiment 
channel data streams. 

Assumptions 

13. The PTC will provide for the generation of all experiment data stream formats 
including dedicated experiment channel data streams. However, the data to fill 
dedicated experiment data streams will not be dynamic. 

14. All data on the payload bus will be simulated at the PTC. The payload bus 
includes two nodes with 1 0 megabits of data on each node. The PTC shall also output 
the data from the systems bus which also contains 10 megabits. 

15. Experiment prototype systems will be able to interface to the PTC data stream 
generator to provide dedicated experiment channel data. 

Brief Summary and Rationale 

Training Viewpoint 

If the PTC is to provide adequate training for the POIC controllers all the 
command uplink capability that is available to the ground must be simulated. 
Telemetry data must be simulated to a level of fidelity necessary to support the 
operations training functions. It may be acceptable to have static data streams for 
some applications but require dynamic simulations for other parameters. If the data 
streams are to interface with actual ground data management system software then 
the data streams must be formatted exactly as the flight data streams. Data acquisition 
and transfer rates must also be assessed to determine their relationship to the training 
objectives. Multiplexing of data within the data stream must also be assessed. 
Generation of the high rate science data streams is desirable but not mandatory for 
POIC operations position training since generally the high rate data is not processed 
at the POIC, but is just passed on to the user facilities. 
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SOS Development Viewpoint 

Telemetry data simulators to some level will be an important part of the 
SCS/PTC. The SCS may be able to obtain and modify telemetry simulation used for 
test. However, due to the high fidelity required for test, and the different purpose of the 
simulation, it often is more expensive to understand and modify than build a simple 
simulation. Developing full fidelity telemetry simulators is a non-trivial amount of 
development effort. 

Operations Evaluations Viewpoint 

Full command uplink capability and downlink of accurate command responses 
are required for the development, evaluation, and verification of ground operations 
procedures and data bases. A key aspect of this issue is the simulation of the 
command responses. Accurate responses are required for proper verification of 
procedures and command data bases. As long as these responses are all included in 
the experiment housekeeping data (assumed to be dynamically simulated in the 
SCS), command responses should be accurate. However, if ground command 
responses are included in the high-rate science data, a dynamic simulation affecting 
the high-rate data stream could be required. 


Recommendations 

o No additional study required. The PTC must support full command uplink 
capability and generation of all payload data stream formats. If the generation of the 
high rate science data streams is a significant impact to the SCS design, then this 
requirement may be deleted. 
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SCS Issue Identification 

Issue Title: Fidelity of Element Control Workstation (ECWS) 

Issue No: T-10 Report Version: 2 


Scope of Potential Requi remsnl 

The scope of this requirement can range from a 
r rw c i n which onlv the on-board crew interface aspects of the ECWS are simuiatea 
to ^high fidelity to a complete emulation o, the flight ECWS by including the 
appropriate Data Management System (DMS) kits. 

Assumptions 

16. ECWS simulators will be provided by WP01 contractor. 

Brief Summary and Rationa le 
Training Viewpoint 

The ImDortant factor concerning the fidelity of the ECWS from a training 

res,: 8 ^ 

characteristics of the flight system. 

SCS Development Viewpoint 

The fidelity of the ECWS simulation is important from a development standpoint 
in terms of ECWS hardware & software. Will special software have to e w 
drive the ECWS in the PTC, or will we be able to use the ground equivalent ECWS 
hardware, and the software that comes with the ground equivalent hardware . 

Operations Evaluations Viewpo int 

ECWS simulators which are adequate for training shouki ®Lf F nw a ||?mutetio 0 n 

SrSSSSSS 

^hbHte^CW^si^ula^o^^hMHght^equ^v^^ntlnterf^e^wou^be^^uired.^ 6 

Rernmmandations 

o Additional study required. Additional study/analysis is needed to determine i the 
imDlications on the SCS requirements from the options of utilizing DMS kits in 
rs mu aSng me ECWS functions within the host PTC system. One purpose of the 
addrttonal s?udy will be to determine the approach to the design of the ECWS. In 
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addition the number of I/O ports required in the SCS for ECWS interface must be 
determined. This will be determined by the number of modules the PTC must support 

(i.e. US Lab, ESA, JEM). 


Related Issues: A-10 
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SCS Issue Identification 

issue Title: Support tor Training Multiple Missions Simultaneously 

Issue No: T-11 Report Version: 3 


Scope of Potential Requi remenl 

The scope of the SCS for the PTC can range from being sized t0 support 
one mission tobeing required to have 4 separate mission independent systems. 

Assumptions 

17 The PTC will be required to support full consolidated experimentoperations 
. . __ o qq inrrpment confiaurations simultaneously (2 U.S. Laos ana 

Sj| M ) whh part taXTa"Lg on 9 individua, experiments from 3 other increments 
(each of the 3 roughly equal to 1/3 of the U.S. Lab in capability). 

18. Development and verification efforts must be able to proceed simultaneously 
with training. 

iq For ourDOses of this study, training and development are assumed to be 
accomplished Sn a 40 hours per week day shift basis, with other hours reserved 
backup, PM, and overflow work.. 

the SSTF. 

Brief Summary and Rationale 
Training Viewpoint 

Tho PTr will be reauired to support both individual experiment operations 

bldevoteSmindivPdual experiment operations train.ngandSmonthso^nso^daed 

» asusKrs? r.agjg 

"Vort ftaneously 3011 3 ° ,h6r 

increments with individual experiment operations training simultaneous y. 

SCS Development Viewpoint 

This issue will have a major impact on SCS hardware and *°J w ® re . 
Supporting multiple missions dictates a multi-tasking operating sys em ( 
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distributed computer/system of some type. Switching hardware and software may be 
required to allow transitions of training on one mission increment to a different 
hardware station (full element trainer from part task trainer (PTTs) or between PITs . 
The requirements will be fairly straight forward. The effect will be in the different SCS 
designs that can be developed to meet the requirements. 

Operations Evaluations ViewDQiDl 

Bv providing simultaneous consolidated training on two different increment 
configurations, the SCS should properly support development and venf'cahon of 
ground and flight crew procedures. Reconfiguration may be required for some 
procedure testing since the procedure development and training schedules may not 
coincide. Plans for procedure development should be investigated to determine the 
correlation with training activities for a given increment and to ensure that the bob win 
properly support the procedure development process. 

Recomme ndations 

o No additional study required. PTC SCS must support simultaneous consolidated 
training as assumed above. Development efforts on other increment experiment 
simulators must be able to proceed while training is in progress. 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Support to Integrated Simulations with Other NASA Centers 

Issue No: T-12 Report Version: 3 


Scope of Potential ReauiremeDl 

The scope of the PTC support to integrated simulations with other NASA 
centers could range from an isolated PTC that does not interface with other SS 
simulations in an integrated simulation environment to a full integrated simulations 
system in which the PTC is an integral part of the SSTF with complete data flow and 
command control capability from other NASA centers. 


Assumptions 

20. A backup interface capability will be required between the PTC and the SSTF in 
order to execute payload simulators in the PTC in support of integrated simulations at 
the SSTF in some cases where it is not feasible to transport the payload simulator to 

the SSTF. 

Brief Summary and Rationale 
Training ViewDQiDl 

The Spacelab experience has demonstrated that integrated mission 
simulations are perhaps the most valuable training exercise that can be provided to 
the operations team, both the flight and ground personnel. Payload operations are an 
integral part of the overall SS operations and must be integrated together in order to 
provide the payload operators with the necessary insight concerning the payloads 
relationship to SS subsystem status. Also it is equally important for the subsystem 
controllers to understand the effects the payloads have on subsystem loads. 

SCS Development Viewpoint 

The JSC assumption that the SCS simulators will run on a separate host, and 
interface through messages and data tables opens the possibility of a joint integrated 
simulation (JIS) through the same interface with the payload simulations running on 
the SCS. This also will have an impact on the SCS, as requirements to support a JIS 
imposes additional computing load requirements on SCS. The capability to remotely 
test a simulation running on the SSTF from the SCS at MSFC would be very handy, 
even if most of the operation of the payload simulations are done by transporting 
payload simulations to the SSTF. 

Operations Evaluations Viewpoint 

Operations evaluation usage of the PTC is not expected to require integration 
with other NASA centers. These functions will be conducted locally at MSFC. 
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Fjppnmmfindations 

o No additional study required. It is assumed that the PTC/SSTF interface will be 
through the SSIS (Space Station Information System). 


Notes/Open Issues 

Will the SCS need to support training sessions at the SSTF with a payload 
simulator running on the SCS? The initial assumption was no, but a revisit based on a 
meeting with JSC has given a current position of yes, for some small percentage of 

payloads. 
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SCS Issue Identification 

Issue Title: Support for Interoperable (Remote Executions) Simulations 

Issue No: T-13 Report Version: 2 


Scope of Potential Requireme nt 


The PTC requirement for support of remote operations could range from o 
remote operation capability of the PTC simulators to a full simulator control and trainee 
interfaces from remote locations such as PI sites, etc. 


Assumptions 

21 . Training done via remote execution is done on the SCS, or the trainees < come to 
MSFC and train here. Thus, the computing load would be the same, and w 
accounted for in the study. 

Brief Summary and Rationale 

Training Viewpoint 

Remote operations capability would make the PTC simulators and training 
capability more accessible to the trainees by potentially providing the training 
capability at their home sites. This would reduce time and travel requ' re me nts^ 
Factors that must be considered in a remote operations capability include both the 
simulation control and trainee interface workstations. 


SCS Development Viewpoint 

Remote execution requirements will affect the SCS hardware design, but not 
the loading. Remote executions will require special interfaces and either a multi- 
tasking operation system (O/S), or a distributed computing system. 


Operations Evaluations Viewpoint 

Remote operations capabilities could allow the PI to perform some procedure 
prototyping and development at his site. However, it is expected that almost aH 
operations evaluation functions will be performed at the PTC. Operations ® va '^ at '° 
functionality is therefore not considered to be a driver on any requirements for remote 

SCS operations capabilities. 

Recomme ndations 

o Additional study required. The affect of remote operations capability on the SCS 
system design must be determined (e.g. distributed processing requ^ements). Also, 
the type of interfaces to remote site workstations must be determined. The potential 
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operation of experiment simulators located at PI sites remotely operated from the PTC 
must also be determined. 

Related Issues; T-14 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for SCS Interface with External Facilities 

Issue No: T-14 Report Version: 2 


Scope of Potential Reauiremanl 

The scope of this requirement could range from the PTC providing a direct 
training support interface with experiment PI sites. User Operation Facilities (UOFs), 
Regional Operations Centers (ROCs), and Discipline derations Centers (DOCs) to 
the PTC only supporting training at external sites via an interface through the POIC. 

Assumptions 

5. Any PTC interfaces to UOFs, DOCs, or ROCs will be through the POIC. There 
will not be any direct data interfaces from the PTC to the UOFs, DOCs, or ROCs. 

20 A backup interface capability will be required between the PTC and the SSTF in 
order to execute payload simulators in the PTC in support of integrated simulations at 
the SSTF in some cases where it is not feasible to transport the payload simulator to 

the SSTF. 


Brief Summary and Rationale 
Training Viewpoint 

The PTC will not have any unique training functions or objectives that require a 
direct interface to any external facilities other than perhaps for remote operations. PTC 
training support to external operations facilities will be through the POIC. 


Development Viewpoint 

The simplest development view was our original assumption of no ®^® rnal 
interfaces except to the POIC. Writing the requirements for interface to the SSTF for a 
jlS is easy. The affect on the conceptual design could include having a separate 
computer to support the JlS functions. 

Operations Evaluations Viewpoint 

The only external facility interface required for operations evaluation functions is 
to the POIC. This interface will provide for the testing of ground procedures in the 
POIC. No unique SCS capabilities in excess of those required to support 
consolidated payload training are required to support this function. 
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Recommendations 

o No additional study required, since there are no unique SCS requirements to 
train personnel at UOFs, DOCs, or ROCs. 

Related Issues: T-2, T-13, A-4 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for PTC Payload Video Data 

Issue No: T-15 Report Version: 2 


Scope nf Potential Requirement 

The scope of this requirement could range from no video data simulation 
capability at the PTC to a software controllable video disk system which would provid 
actual dynamic video data that could be controlled by the PTC simulators. 

Assumptions 

22. No SCS simulation of EVA or SCS production of other rendered outside attached 
payload pictures. 

Brief Summary and Rationale 

Training Viewpoint 

For many experiment operations, the video data is the primary source °* 
science data. However, from a training standpoint, what must be considered |S 
role the video data plays in operational decisions. For many experiments static video 
datamay be acceptable, but for other operations a full dynamic video simulation 

capability may be required. 

SCS Development Viewpoint 

Recent advances in graphics hardware and software make video scene 
generation simulation possible today that would have been impossible or extremely 
SSSe e^en as short a time ago as 3 years. Si. notation. ™ «£ 

graphics hardware and software, on graphics hardware and video d sk , o r g n aph.cs 
hardware and large storage optical disks and CD ROM. Various COTS rapid 
prototyping tools are maturing that might also support some required video 
simulations. Details of the requirements in this area will/can result in a wide variety of 
design solutions, but requirements must be detailed enough to allow designers to 
determine the proper level of solution required. 

Operations Evaluations ViewPQinl 

A key operations evaluation usage of the PTC could be for the pratotyping and 
evaluation of payload video systems. To support evaluation of video systems intended 
for final use in the on-board environment, a flight-equivalent payload video system will 
be required to provide the correct interfaces. 


Rar.nmmendations 
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o Additional study required. Additional analysis is required to determine the 
potential requirements for payload scene data required to support training and the 
aspects of the potential video data that will affect the SCS requirements. Also any 
requirements to digitize video data and put it into a data stream must be determined. 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for Simulation Parameter Update Rate 

Issue No: T-16 Report Version: 3 


Scope of Potential Requirem ent 

Simulation parameter update rates can range from once per second to the 
maximum data acquisition rate of the SS Data Management System. This 
requirement basically determines the processing time requirement for the simulators 
that are driving the dynamic parameters. 


Assumptions 


23. The standard update rate (required to support realistic displays for the trainees 
in the PTC) for the SCS for dynamic data will be once per second. A subset of the 
simulator tasks (required to support realistic input by the trainees) will be required to 
execute at up to 10 Hz rate (e.g. response to hand controller inputs). A rate of 25 Hz 
may be required for pointing systems. 


24. To work with the core subsystem flight equivalent hardware and software, the 
SCS must work at rates that satisfy this flight equivalent hardware and software. 


25. Onboard data storage capability of the DMS will be part of the DMS simulation 
capability provided by JSC/WP02. 


Brief Summary and Rationale 


Training Viewpoint 

From a crew operations training viewpoint it is only necessary to update the 
dynamic parameter data at the rate at which the crew can view the data. For example, 
if the data display system will only update parameter data on a once per second basis 
it is not necessary for a simulator to execute at any faster rate because once per 
second is the most granularity that the trainee could ever see in the data. However, for 
POIC console operations training in which recorded data may be accessed that was 
acquired at a faster rate it may be necessary to simulate that data acquisition rate if 
critical data points could have individual sample values and/or trends that occur at the 
faster acquisition rate. 

sr,R Development Viewpoint 

These rates will have an effect on conceptual design candidate hardware. How 
often a simulation must run, how large it is, and how many others running at the same 
speed, and their size, will be big factors in the size and speed of the required SCS 
computer (s). The more detailed the data and requirements we have, the better will be 
our selection of hardware. 
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Operations Evaluations Viewpoint 

Since the SCS is assumed to include one or more DMS Kits, it is required to 
support the data acquisition rates of any flight software utilized. If simulated 
parameters are updated at the rates they are acquired by flight software, all operations 
evaluation functions should be adequately supported. For "pure simulators (those 
with no flight hardware/software components), parameter update rates which 
adequately support both flight crew and ground personnel training should also suffice 
for operations evaluation functions such as procedure development and testing. 

Recommendations 

o No additional study required. SCS must support execution of simulations at a 
standard rate of 1 Hz with the capability to also execute some tasks at up to a 25 Hz 
rate. 


Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for High Rate Data 

Issue No: T-17 Report Version: 2 


Scope of Potential Requiremen t 

The scope of this requirement can range from no dedicated experiment channel 
data simulation to a complete simulation of all the science and operations data that is 
downlinked via dedicated experiment channel data streams. This requirement could 
also imply a requirement to have high data rate recorders as an integral part of the 
PTC to record simulated high rate data for downlink at some time after the expenment 

operation. 


Assumptions 

13. The PTC will provide for the generation of all experiment data stream formats 
including dedicated experiment channel data streams. However, the data to fill 
dedicated experiment data streams will not be dynamic. 

Brief Summary and Rationale 


Training Viewpoint 

In the Spacelab training experience, the simulation of dedicated experiment 
channel data was not supported by the PCTC. This did not lead to any s0 riou s 
deficiencies in the training environment for the payload crew or for the POCC cadre. 
However in many cases dedicated channel data is the only source of experiment 
operations status and science data that is available to the experiment control teams on 
the ground. This led to situations during Spacelab training where more data was 
available to the flight crew in the training environment than was available to the 
experiment control teams on the ground. The PTC support responsibilities for training 
the experiment PI teams and to provide an interface for prototype experirnent 
hardware will be the primary driver in determining the need for dedicated channel data 
simulation. 


SCS Development Viewpoint 

The rates for generation of all dedicated channel data formats will be a 
significant factor in communication channel selection. Data will be simulated by data 
tables, not dynamic simulators. Data may be provided by a PI provided generator. 

Operations Evaluations Viewpoint 

Accurate responses are required for proper verification of ground procedures 
and command data bases. As long as these responses are all included in the 
experiment housekeeping data (assumed to be dynamically simulated in the SCS), 
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command responses should be accurate. However, if ground command responses 
are included in the high-rate science data, a dynamic simulation affecting the high-rate 
data stream could be required to provide effective test capabilities for ground 
procedures and command data bases. Evaluation of prototype experiments and 
payload data management technologies may also require a flight equivalent high rate 
data system to provide the appropriate interfaces. 

Recommendations 

o No additional study required. The PTC will support the generation of all 
dedicated channel data formats. However, if this requirement is a significant driver on 
the SCS design, it may be relaxed. 


Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for Virtual Instruments 

Issue No: T-18 Report Version: 2 


Scope of Potential Requirement 

The scope of this requirement could range from no virtual instrumenl • P® n ®j 
simulation Ability in the PTC to a requirement to be abe to emulate 
experiment control and display panel as a virtual instrument in a workstation 

environment. 

Assumptions 

26 Virtual instruments are acceptable in the part task experiment simulation 
workstations, but should not be utilized in the consolidated increment training 

environment. 

Brief Summary and Rationale 
Training Viewpoint 

Virtual instruments are not desired as training systems for the full fl, 9 ht ®'®™®"| 
configuration training but are probably quite acceptable for individual experiment 
training utilizing Computer Based Instruction systems and possibly even in the part 
task trainers for individual experiment operations. 

SCS Development Viewpoint 

Recent advance in Programmable Entry Panels (PEPs), P ro 9 r ® m ™®b'® 
switches, touch screens, LCD displays, and large screen displays make vulual 
instruments very attractive as a design solution to SCS requirements where the fidelity 
does no! neS to be 100%. It is possible to create a very flexib to generalized, and 
easily reconfigurable trainer. It seems sensible to tune the SCS fidelity requirements 
to take advantage of these types of hardware and software. 


Operations Evaluations ViewPQiQl 

Virtual instruments have the potential for very valuable usage in the operations 
evaluation arena They could be used by experiment developers and other operations 
personnel to prototype V and evaluate potential instrument designs to provide input to 
the instrument development process. To provide the highest value for this W® ° 
evaluation, a capability to rapidly configure prototype sim u|at| ° n st° support ^virtual 
instruments is also required. A full experiment prototype could thereby be rapidly 
constructed and evaluated in advance of the actual experiment development process. 
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Recommendations 

o No additional study required. Virtual instrument simulation capability will be a 
part of the part task experiment workstations. 


Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for Simplified Simulator Operations Setup and 

Control 

Issue No: T-19 Report Version: 2 


Scope of Potential Requi rement 

The scope of this requirement ranges from a system with a fixed simulation 
confiauration and make-up that is predefined at initial boot of the host computer 
svstem to a totally flexible system in which the simulation conductor can define the 
complement ofsimulamrs and the training workstation configurations that he destres 
for any given training session. 

Assumptions ”> 

Brief Summary and Rationale 

Training Viewpoint 

In order to maximize the efficiency of the PTC to support multiple flight 
increments it is essential that the simulation conductors have the ability to control tha 
contents of any given session. The complement of experiment and subsystem 
simulators that are to be executed must be selectable by the simulation director and 
the location/configuration of all workstations involved in the training exercise must be 
under the simulation directors control. 

SCS Development Viewpo int 

These types of requirements are very difficult to write so that they are testable. 
Based on our experience with trainers and operational systems, however, we can 
write requirements having to do with which function controls what, re ^'9 l l ra ^" 
control and timing, freeze points, restart points, synchronization of f “ n £tions a d 
initialization timing and control. Other, more general design goals will have to be 
included in the function specifications as design goals. 

Operations Evaluations Viewp Qinj 

Simplified setup and control functions which fully support training should be 
adequate for all operations evaluation functions. The operations evaluation functions 
impose no unique requirements in this area. 

Recomme ndations 

o No additional study required. This is an operational design issue but is not a 
significant driver to the SCS design. 
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SCS Issue Identification 
Issue Title: Support for Onboard Training 

issue No: T-20 Report Version: 0 


Scope of Potential Requirement 

The scope of this requirement ranges from no SCS support for onboard training 
to use of the SCS as a node to support training for crew onboard the Space Station. 

Assumptions 

27. There are currently no requirements for onboard training levied on the SCS. 
Brief Summary and Rationale 
Training Viewpoint 

It is possible to envision the PTC/SCS as a node to conduct training for crew 
onboard the Space Station. However, the most likely situation would be to have PTT 
software that could be transported to the Space Station to be used there for onboard 
training. 

SCS Development Viewpoint 

Onboard training would be a factor in development of simulations. The size, 
and the host machine on which they run might be different. Also, using simulations 
onboard raises issues of verification, validation, and flight rating the software. 
Depending on the payload, and where the simulation software runs, software safety 
issues might also be a factor. 

Operations Evaluations Viewpoint 


Recommendations 

o Additional study required. This is a new issue, and will be tracked as the SCS 
Study proceeds. 

Open Issues/Notes 
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DEVELOPMENT ISSUES 
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SCS Issue Identification 
Issue Title: Utilization of SSE Capabilities 

Issue No: A-1 Report Version: 2 
Scope of Potential Requirement 

The scope of this requirement could range from having the SCS be fully 
compatible with the SSE environment to having the SCS be largely independent of 
the SSE environment. 

Assumptions 

28. SCS will use SSE capabilities for software development and maintenance. 

Brief summary and rationale 
Training Viewpoint 

The utilization of the SSE capabilities is not important from a payload crew or 
ground operations personnel training standpoint but may be significant from the 
standpoint of training the operators, training personnel, and developers who utilize the 
PTC. Since the SSE provides standard interfaces and capabilities that will be utilized 
by individuals throughout the payload community involved in the Space Station 
Program, it is essential that the PTC conform to these same standards. 

SCS Development Viewpoint 

There is excellent potential for increased productivity in the development area 
using a proven set of tools to develop the SCS system. There is also good potential 
for lessening of life cycle maintenance costs using the SSE environment. It makes 
sense from a compatibility standpoint to utilize SSE. Utilization of SSE will make it 
easier to transfer/use flight equivalent software. Transporting simulations from the 
SCS to the SSTF should be eased by using SSE. Common use of SSE CM tools 
should help inter-center transfer of software and data. SSE will provide CBT tools, 
and these need to be considered in the conceptual design phase of the SCS Study. 

Operations Evaluations Viewpoint 

The operations evaluation function imposes no unique requirements relative to 
the utilization of SSE capabilities. 

Recommendations 

o No further study required. 

Requirements - The SCS system shall follow completely the SS SSE 
guidelines, and fully utilize the SS SSE capabilities. 
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Indications - We need to understand the full implications of SSE on the .design 
current^piSined'^E dS^^'T?!^ 1 Halysls^and'our 

SSSSssr. -avs - ■ 

Related Issues : A-13 
Open Issues/Notes 

?«»..« w»... <» SCS .««». »» »"»“•' ' 

this is the current SSTF plan. 
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Issue Title: 
Simulators 


SCS Issue Identification 

Techniques for Integrating and Maintaining Pl-Provlded 


Issue No: A-2 Report Version: 3 
Scope of Potential Requirement 

The scoDe of this issue ranges from having the Pis develop and test their 

simulators on the PTC/SCS to allowing **j [T pIc/SCS^ and 

independently, and integrating them with the PTC/SCS after they are h 

tested. 

Assumptions 

29 For purposes of loading for the SCS study, all simulations are assumed to be 
built, integrated tested, and maintained on the PTC/SCS. Sizmg must be done for 
worst case. 

Brief summary and ratio nal 
Training Viewpoint 

If experiment simulators are developed by the Principle Investigators and 
integrated into the PTC, there could be a significant impact to the task o frarning me 
personnel who will conduct the training sessions at the PTC. In order to conauCT a 
trainina session the simulation director needs to have a thorough working kn °wtedge 
of the software being used in the training session. Typically, this knowledge is 9 a ' n ® 
frnm pither a familiarity with the original training and simulator requirements o 
software development process. If simulators are developed e,se ^® r ® ^ d M gp£ 
fnteorated into the PTC then another means will have to be developed for MSFC 
personnel to aain the knowledge necessary to conduct the training sessions. The 
utilization of computer aided instruction may serve to provide some of the necessary 

knowledge. 

SCS Development Viewpo int 

Havina the simulators developed on the SCS would be helpful in eliminating 

then integrated will create its own special set of problems. 

This problem can be segmented into: 1) Computer Based Training (CBT) 

which it would seem logical for the Pis to do, 2) Individual ex P®™®"' , ™"! n b 9 J p.^ ® r 
might be handled via a standard part task trainer (PTT) approach done either by Pis or 
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PTC, and 3) Integrated training, which would have to be a PTC responsibility, but 
which could use software developed under 2 above as a base. 

Off site simulator development problems include successfully communicating 
interfaces to the off site developers, having unit test and SCS integration occurring in 
potentially slightly different run time environments, and insuring enough commonality 
to yield a reasonably short integration period. Independent PI simulator development 
drives the SCS requirements toward the use of DMS Kits for program standard 
interfaces. 

Operations Evaluations Viewpoint 

To support applications such as the evaluation of prototype experiment designs 
or the use of different payload data management techniques or technologies, the SCS 
must provide standardized, well-defined interfaces for the integration of externally 
provided simulators or prototypes. This capability would allow Pis or operations 
personnel to develop prototype payload simulators, bring them to the PTC, ana 
evaluate different operational concepts for payloads under development. These types 
of evaluations could then provide feedback to the payload control software 
requirements analysis and design processes. 

Recommendations 

o No further study required. 

Requirements - The SCS shall provide all the capability needed to develop and 
maintain all the Space Station Program payload training simulators, including those in 
the U.S. Lab, the attached payloads, and TBD number of payloads from the 
international partners. 

Implications - This development load will be a big factor in sizing the SCS 
capability. This will be used in the conceptual design tasks. 

Related Issues : A-3, A- 11 

Open Issues/Notes 

What is the difference between making the SCS available to the Pis and having 
the PTC/SCS people build the simulators? Do we need more terminals, more DMS 
Kits, or merely a remote capability? 

The level of involvement of the international partners needs to be defined. This 
issue is currently being brought to the Training Working Group. 
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SCS Issue Identification 

Issue Title: Techniques for Supporting Late Changes to Simulators 

Issue No: A-3 Report Version: 2 


Scope of Potential Requirement 

The bounds on this issue are how close to launch you allow changes in the 
simulators, and also the magnitude of the late changes. Small changes made late 
may be of little consequence, yet we know large changes made too late in the cycle 
can have very adverse affects on not only the changed experiment, but other SCS 
supported simulation activities. 

Assumptions 

30. Late changes to the simulators are a problem that the PTC/SCS people have to 
solve. 

Brief summary and rationale 
Training Viewpoint 

The only impact this issue has from a training viewpoint is that if personnel other 
than the PTC personnel are incorporating late changes into the simulators then some 
method must be established to keep the training personnel aware of late 
developments that need to be incorporated into the training scripts. 

SCS Development Viewpoint 

The lowest cost solution from the development viewpoint is to baseline the 
requirements before design work on the simulator begins, and never change them. 
Allow no late changes in the simulators. This of course is not practical, as the real 
flight hardware and software are often still changing late into the training cycle. Thus, 
as much accommodation of the late changes in simulators as can be done in some 
reasonably cost effective manner must be incorporated into the SCS system. This can 
be done through modular design of the simulators, maximum use of reusable software 
libraries, maximum use of software productivity tools and helpful software 
development environments, and use and retention of experienced, sharp 
software/simulator developers. The key SSE CM capabilities may be useful here too - 
specifically the change/implementation tracking done using automated SSE tools like 
APCE. Maximum use of flight software and prototype/engineering hardware could 
help alleviate some of the adverse affects of late changes. 

Operations Evaluations Viewpoint 
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Techniques for supporting late changes to simulators which fully support 
training should be adequate for all operations evaluation functions. The operations 
evaluation functions impose no unique requirements in this area. 


Recommendations 

o Further Study Required. 

Requirements Example - The SCS system shall be capable of incorporating a 
"minor change * see below - into an SCS simulator in 5 working days. Incorporate 
includes design, code, test, and integrate only - documentation time is separate. 

Implications - This will have implications on both the requirements and the 
conceptual design. 

Study Definition - Study will be made of state-of-the-art simulation development, 
emphasizing how quickly changes can be incorporated and tested. Also, other 
simulator systems with problems and characteristics similar to the PTC/SCS will be 
contacted and surveyed as to how they deal with this type of problem. We will 
definitize and categorize changes, i.e. a "minor" change will be defined in terms of 
scope, and then a requirement can be written as to how quickly a "minor" change is 
required to be incorporated into SCS simulators. It is important to know the current 
state-of-the-art so that we produce requirements that can be met. Another approach 
would be to define several simulation "conceptual frameworks" - e.g. 1) all software 
simulations with minimal DMS Kits, 2) DMS Kits plus software experiment models, 3 
hybrids of DMS Kits, experiment flight equivalent hardware and software models, 4) 
DMS Kits, flight equivalent experiment hardware and software - and evaluate the 
framework pros and cons with respect to accommodating late changes by framework 
category. 

Related Issues : A-2, A-11 
Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Allowing Software Transportability between SCS and Other 

Centers 

Issue No: A-4 Report Version: 4 


Scope o 1 Potential Requirement 

Software can be totally transportable to/from the SCS and other SS centers, or not 
transportable at all between centers. 


Assumptions 


31 . Recent 
period before 
SSTF. 


top level agreements that the crew will train together at JSC the 
launch dictate that the SCS simulations will be transportable to the 


32. The PTC/SCS people at MSFC will be responsible for maintenance of the 
payload simulators, including the period when the simulators are used at the Sblh. 

33. Integration of the payload simulators into the SSTF will be through a 
JSC/MSFC agreed upon method. 


34 There must be a capability to simulate payloads, if only for simulator 
maintenance, at the PTC/SCS for the duration of the payload’s mission hfe. Thus - » a 
payload simulator is both hardware and software, the hardware may be duphcated 
virtual panels may be used, or a parallel software simulator may be developed m order 
to retain the payload simulation capability at the PTC/SCS. The duphcate/substitute 
simulator may be employed at JSC in place of the original hardware/software 

simulator at the PTC. 


Brief summary and rationale 
Training Viewpoint 

Having software be transportable to/from other SS centers has many 
advantages from a training standpoint. It gives great flexibility in the training^ locations 
and scheduling when crew training can take place. It allows varying le ^ e '® of '"' ng 
to be done at different centers by combining simulators developed for different 

purposes at different centers. 

SCS Development Viewpoint 

A requirement for transportability would force some level of commonality of 
hardware and run time environments which might limit the choices for the SCS 
hardware and software such that the SCS could not accomplish it's primary mission of 
training payload operators. However, commonality tends to decrease life cycle cross 
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training and maintenance costs. The SSE should be the common starting point for 
allowing transportability. Run time environments are covered by our assumption 
above, but no matter what the assumption, the similar nature of SCS and SSTF will 
very likely allow selection of a common payload training host computer. Virtual panels 
may be built for PTC use when the actual hardware is at the JSC/SSTF, or the virtual 
panels may be sent to JSC for use in the final training period before launch. 

Operations Evaluations Viewpoint 

To support applications such as the evaluation of prototype experiment Resigns 
or the use of different payload data management techniques or technologies, the SCS 
must provide standardized, well-defined interfaces for the integration of externally 
provided simulators or prototypes. Operations evaluation functions impose no unique 
requirements in the area of transportability to other centers except that capabilities to 
allow this transportability must not preclude the provision of operations evaluation 
capabilities. For example, SSTF commonality requirements must not preclude 
capabilities for the evaluation of prototype payload hardware/software. 


Recommendations 

o No further study required. 

Requirements - The SCS developed payload simulators shall be fully 
transportable to the SSTF facility at JSC. Transportable is defined as being able to 
run on the SSTF provided payload simulation computer, interface to the SSTF 
element trainers, and interface with the SSTF systems simulators (including DMS Kits, 
SSTF system simulations, and flight software). 

Implications - Close coordination will be needed on a continuing basis between 
JSC and MSFC NASA and contractor people as the SSTF and the PTC/SCS are 
designed and built in order to specify interface agreements and make common design 
decisions that will support the required transportability. 

The SSTF will have available a run time environment that will support SCS 
developed simulators, e.g the payload computer system shown on the JSC charts will 
be compatible with the SCS computer. 


Related Issues : A-1 , T-1 4 


Open Issues/Notes 

What about a complex payload simulator that includes a significant amount of 
hardware 9 Does this, once installed at the SCS, remain here during the last 3 months 
of training (done at the SSTF), with a remote operations of this simulator to support the 
SSTF training, or do we levy a requirement to duplicate the hardware? The current 
answer is that we should levy requirements to duplicate the hardware. 
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SCS Issue Identification 

Issue Title: Techniques for Integrating Payload Flight 

Hardware/Software with SCS Simulators 

Issue No: A-5 Report Version: 3 


scope of Potential Requirement 


The scope of this issue ranges from no integration of '° 

hill integration and use of flight hardware and software with the SCS simulato . 

Assumptions 

Brief summary and rationale 
Training Viewpoint 

environment. Malfunction training may a Q om nuter System standpoint all the 

to initiate fault insertion and to monitor ^the trainees respons^ ^ ^ pJC must be 

Somplishld | e in' n a e mfnner C °lo insire that a proper training environment is being 
provided that will meet the specified payload training objectives. 

SCS pavelopment Viewpoint 

Building flight hardware/software in parallel with ““XThe^rsIwwTnTI 
U " fflgh!'°e W st’har2areToufd most likely provide better fidelity, and certainly 
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would yield more confidence in the accuracy of the training achieved. There is of 
course the problem of introducing anomalies when using flight equivalent hardware 
and software. Break out boxes can be used to introduce anomalies. 

Operations Evaluations Viewpoint 

Using flight hardware and software would give the highest confidence possible 
for any operations evaluation purposes that the evaluation would be accurate. 

Many operations evaluation functions will require the capability to integrate 
candidate or prototype flight hardware/software with the SCS simulators. Therefore, 
the SCS must provide flight-equivalent interfaces especially in the areas of data 
management and communications (including audio and video). The SCS must also 
provide the capabilities to execute and evaluate prototype flight software which may 
be supported by prototype software simulations. This capability would allow for the 
analysis and evaluation of candidate experiment control software designs. 

Recommendations 

o Further Study Required. Study Definition - We must know enough about the 
details of what will be required of the SCS to support use of payload flight hardware 
before we can write the SCS requirements. Some of this knowledge is in house, and 
some will come from contacting others knowledgeable about SS payloads. The SCS 
requirements we write must reflect what is needed both in terms of software and 
hardware required, and hooks and scars required in the SCS system. 

Related Issues : T-6.T-8, A-10, A-14 

Open Issues/Notes 

Do we need DMS Kits in order to support flight equivalent payload hardware? 
Some payloads will require these, and some will make minimal use of DMS. 
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SCS Issue Identification 

Issue Title: Flexibility for Allowing Advanced Technology Insertion 

Issue No: A-6 Report Version: 3 


Scope of Potential Requirement 

The scope of this issue is to limit the planning for further advances in technology 
that can be inserted into the SCS to allowing the maximum possible Advanced 
Technology Insertion. There are two different technologies included in this issue: 1) 
Technology that will be inserted into the Space Station, and 2) Simulation technology 
that will need to be inserted into the SCS. 

Assumptions 

36. Assume the Space Station life cycle is 30 years, but that computers, displays, 
and other COTS electronic equipment will have to be replaced or upgraded at 
intervals ranging from 5 to 10 years. 

Brief summary and rationale 

Training Viewpoint 

The flexibility for advanced technology insertion is mandatory from a training 
standpoint because over the expected life span of the Space Station the experiment 
operations will continue to evolve and utilize advancing technologies. The PTC SCS 
must be able to provide the consolidated training environment for these advanced 
technology applications. 

SCS Development Viewpoint 

There is a directive from congress, and a NASA Technical Memorandum 
(87566) entitled "Advancing Automation and Robotics Technology for the Space 
Station and for the U.S. Economy" that emphasizes the need for the Space Station, 
since it will have a lifetime of decades, to provide for and aid in the advancement of 
technology in general, and specifically automation and robotics - which includes 
artificial intelligence (Al), voice synthesis, voice recognition, natural language, 
computer vision, image analysis, and teleoperations. This would indicate we should 
look at ways to provide for insertion of a variety of Space Station advanced 
technology. Of course, from a development point of view, it is less expensive to limit 
the amount of time and worry about this issue. The worst case would be to provide 
very limited capability for technology insertion in the beginning of SCS development, 
and later in the development cycle decide that technology insertion must be done on a 
very large scale. 

In terms of simulation technology, there has been a great deal of work done in 
the past 5 years in advancing rapid prototyping, display technology (that makes some 
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_ ren o Generations options open today that were simply not possible just a few years 
JJiri romDuter technology. This too indicates that the SCS system should be 
^ in take advantaae of new advances in computer technology, display 

S*noSw°us^nwSoetech™DlOfflr- that may also be inserted into the Station as 
well as the training facilities - and general advances in simulation technology. 

Operations Fvaluations VieWDQiQl 

It is aDDarent that to provide effective training, the PTC must incorporate new 
technology whtetfaffeas the* payloads on the Space Station The new technolog.es 
mav be simulated or flight equivalent hardware/software may be installed in the PTC 

app^m^te M^bi^^^or^valuation^f candidatMechnologies for^rassible insertion 
into the Space Station environment. 

Recommendations 

o Further Study Required. 

RamDle Reauirements - The SCS shall have the necessary software hooks and 
hardwam s?ars tobe able to accept , with minimum 

Station technology, including computers, displays, user interface, Al, and robotics. 

The SCS shall have the necessary software hooks and hardware scare t^ b® 
able to accept with minimum perturbation, advances in simulation technology, 
fncludlng^ K ^splays, user interfaces, Al, CAI, and simulation languages. 

Studv Definition - A projection of all the technologies listed in the above sample 
reauirements will be performed using in house knowledge and oth er existing 
Ml Tu. rpcnite of this will then be used to write some more realistic and 

detailed requirements. The results will also be used to guide the conceptual design 
tasks (tasks 4 & 5) to influence the conceptual design to include features that Wll > ease 
£t ure C !echnology insertions. As we do our conceptual design, we especially need to 
locate and identify scars and hooks that are needed. 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Implications of Simulation Development Cycle 

Issue No: A-7 Report Version: 2 


Scope of Potential Requirement 

There are two aspects to this issue. One is the amount of simulation 
development done on the SCS computers. Do the Pis develop the simulators on the 
SCS, or do they all have access to an SPF that will allow them to build simulators. 
The second aspect is when in the cycle the simulators are built. This will affect 
whether early experiment prototype simulations are built and used, or if the only goal 
is to build and use the as-built simulations. 

Assumptions 

29. For purposes of loading for the SCS study, all simulations are assumed to be 
built, integrated, tested, and maintained on the PTC/SCS. Sizing must be done for 
worst case. 

Brief summary and rationale 
Training Viewpoint 

The simulation development cycle has a significant impact on training as the 
consolidated training program is dependent upon simulators being developed in a 
timely manner to support the training cycle. In many cases, development and training 
have to parallel actual experiment development. Simulators have to be available far 
enough ahead of a launch date to provide adequate training on each experiment. The 
more complex an experiment's operations are the more time it takes to develop a 
realistic simulator but it also takes a great deal more time to train the crew members on 
these complex experiment operations. 

SCS Development Viewpoint 

This issue has a potentially large affect on the SCS, how big it is, and what it 
looks like. If all simulations are developed on the SCS, the SCS resources would be 
significantly larger than if few or none of the simulators are built on the SCS. The 
phasing and method of building simulators (from experiment prototype simulators to 
as-built simulators) will also have a potentially large affect on the SCS requirements. 
If experiment prototype simulators are built, this will affect the load on the SCS. 
Perhaps more importantly, if COTS rapid prototyping is used, this might lessen the 
load on the SCS, or require different hardware to be available as part of the SCS. 


Operations Evaluations Viewpoint 
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There are no unique operations evaluations considerations in the main training 
simulation development cycle. However, a simulation rapid prototyping capability is 
required for use in evaluating new payload control concepts, user interface 
techniques, etc. For example, this capability would allow operations personnel to 
construct prototype experiment displays and control software and use a simulation 
built with rapid prototyping tools to evaluate the operation of the experiment. 
Succeeding tests could then be run against the same simulation to compare different 
user interface techniques. 

Recommendations 

o Further Study Required. Study Definition - We will continue to define the 
simulator development load, expanding on what we have already done and 
discussed. This will be combined with the assessment of the training load, also 
ongoing, with the result that we will have a good idea of the total load that the SCS 
must support. 

Related Issues : A-2 

Open Issues/Notes 

Separate development and simulator IT&V facilities may be required like the SSTF. 
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SCS Issue Identification 

Issue Title: Sizing Growth Potential in Capability/Capacity 

Issue No: A-8 Report Version: 3 

Scope of Potential Requirement 

The scope of this issue is to have a small reserve in capacity/capability to 
having a large reserve in capability/capacity. 

Assumptions 

36. Assume the Space Station life cycle is 30 years, but that computers, displays, 
and other COTS electronic equipment will have to be replaced or upgraded at 
intervals ranging from 5 to 10 years. 

Brief summary and rationale 

Training Viewpoint 

Any system upgrades that are incorporated into the SCS must be accomplished 
in a manner that does not impact ongoing training activities. Since many experiments 
may re-fly several times on the Space Station, it is important that the experiment 
simulators be re-usable and available for training on later missions. If system 
enhancements and modifications are made, then the already developed software 
simulators and interfaces to existing experiment hardware must be compatible to 
continue to support training. Otherwise, the maintenance activity for experiment 
simulators that were developed under previous versions of the SCS will be 
significantly increased and could affect the availability of a simulator to support 
planned training schedules. 

SCS Development Viewpoint 

The less reserve capacity in a system, as long as the system is fully functional, 
the less the system costs initially. The greater the uncertainty in the requirements and 
the data sizes and scenarios used to generate the requirements, the greater should be 
the requirement for reserve growth potential capability/capacity. Also, the longer the 
expected lifetime of a system, the greater the need for larger margins in 
capability/capacity. 

This issue also relates to the ease of growth, i.e. replacement of hardware 
without modifying applications software. 

Operations Evaluations Viewpoint 

The operations evaluation function imposes no unique requirements in the area 
of growth potential in capability/capacity. 
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RppnmmendatiQns 

o Further Study Required. In conjunction with the study on training load and 
development load on the SCS, we need to define the SCS capacity in terms of the 
number of developers supported, the number of different payloads the developers are 
working on, the complexity of each of the payloads, the number of students being 
trained the number of different increments supported at one time, and the number of 
instructors. These can then be turned into SCS requirements. Also, they will be key in 
the concept definition tasks. We also need to define the computer parameters that will 
define growth potential. It also would be useful during the conceptual design task to 
plot growth vs. cost. 

Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Defining Telemetry Data Format and Calibration 

Issue No: A-9 Report Version: 2 


Scope of Potential Requirement 

The scope of this issue is to have the SCS output realistic telemetry data in 

packet format, to having the SCS bypass the POIC front end, and put data into the 

POIC in engineering units that can go right into the POIC. 

Assumptions 

Brief summary and rationale 
Training Viewpoint 

The simulation fidelity requirements for formatting output data into the proper 
telemetry formats relates to the functions of the personnel that are using the simulator 
system for training. In the Spacelab training environment, the initial object of the 
simulators was to train the payload in on-board experiment operations. For this 
reason, it was only important to provide data in the engineering unit format that was 
available to the on-board crew. Uncalibrated raw data formats would have little 

meaning to the crew members. For the Space Station training it will be equally 

important to train ground personnel who will be handling data in flight formats. 

SCS Development Viewpoint 

Not having to deal with telemetry data in packet form is obviously a cost 
savings, unless the DMS Kits provide this processing as part of their services. 
However, if integrated simulations with JSC or other SS Centers are to be done 
remotely, this could be very difficult unless the SCS can produce telemetry with 
packets in the real format. Building the SCS without the capability to produce 
telemetry data in the real form with packets will place a limitation on the future use of 
the SCS. Also, building the ability to produce telemetry in the proper format may prove 
cost effective in the long run if there are uses, since the packet form should ensure 
compatibility with a broad range of users. 

Operations Evaluations Viewpoint 

For development and testing of ground procedures and data bases, the SCS 
must provide telemetry data to the POIC. This data must provide realistic responses to 
ground commands but the actual format of the telemetry data transmitted from the SCS 
is not driven by any operations evaluation requirements. 
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Recommendations 

o No further study required. However, for the current purposes of the SCS 
Study this issue will be considered open. The potential for gains in flexibility and 
capability may outweigh the cost of this currently "not needed" capability. This will be 
looked at in the conceptual design phase. 

Related Issues: A-5. If part of a simulator produces real telemetry, we will need 
realistic telemetry data. 

Open Issues/Notes 
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SCS Issue Identification 
Issue Title: Fidelity of DMS Interface 

Issue No: A-10 Report Version: 3 


Scope of Potential ReQuireme.pl 

The scope of this issue ranges from having a limited hardware/software simulation to 
having a DMS Kit. 

Assumptions 

8. The PTC will not be responsible for any subsystems training. However, the PTC 
will utilize minimum subsystem interfaces as necessary to support payload training. 

12. The PTC will utilize DMS Kits that are provided by JSC/WP02. 

37. A host-based DMS functional simulation (FSIM) to be provided by SSE will 
NOT run in real time. Thus, FSIM is assumed to be of minimal utility in the SCS. 

Brief summary and rationale 

Training Viewpoint 

The DMS will be a major interface device for payload crew control of payload 
experiment operations. The fidelity of this interface must be near flight type in order to 
provide an adequate training environment for the payload crew. The characteristics of 
the keyboard and terminal must be flight like in order for the trainee to gain the proper 
familiarity with the control and monitor interface. 

SCS Development Viewpoint 

Some systems interaction will be necessary to have a realistic enough 
simulator for payloads. The level of interaction between the experiments and the 
system is a large factor in the requirement for a high fidelity DMS simulation. It 
appears that the level of interaction between experiments and the DMS may be fairly 
high, and this would indicate that a fairly high fidelity simulator will be required, or the 
use of real DMS hardware/software will be required. 

Operations Evaluations Viewpoint 

A flight-like DMS interface is required for the evaluation of prototype 
experiments and prototype experiment control software. Both the physical DMS 
interfaces and software interfaces are required. The physical interfaces (FDDI and 
local busses) will be used for the connection of prototype experiments or prospective 
payload data management hardware. The software interfaces (Operating System, 
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CUI, OMA, and DMS services) will be used to provide a flight-like environment for the 
execution of prototype user interfaces and payload control software. 

Recommendations 

o Study required. This study is associated with the one for A-5 - Techniques for 
integrating flight hardware and software with the SCS. The fidelity of the DMS 
interface will affect the SCS ability to interface with flight hardware and software. 

Sample requirement - The SCS will interface to the DMS to the level sufficient 
to support payload training. 

Related Issues: T-8.T-10, A-5, A-14 

Open Issues/Notes 

A key part of this issue is the possible requirement to run flight (experiment) 
software in the SCS. The use of prototype hardware may require DMS Kits. 

The requirement to transport SCS payload simulators to the SSTF also affects 
the way in which the SCS simulates the DMS interface. 
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SCS Issue Identification 

Issue Title: Definition of No Single Point of Failure 

Issue No: A-11 Report Version: 4 


Scope of Potential Require ment 

This issue involves the level of need for backup for every SCS component, . and 
the consequent cost of not having a backup for every component, i.e. no single point o 

failure. 

Assumptions 

Brief summary and rationale 
Training Viewpoin t 

No single points of failure is an extremely important issue from the training 
viewpoint. It is important that the PTC be able to conduct its training P ro 9 r a m s without 
significant impact due to system hardware failures. In most cases, the schedules oft e 
personnel involved in training will be booked solid far in advance which will rna 
next to impossible to reschedule a training session that has to be canceled due to a 
facility problem. Consolidated training exercises that involve experiment team 
representatives with the crew and ground operations cadre may involve travel for a 
large number of the participants that cannot be rescheduled without significant costs to 

the program. 

SCS Development Viewpoint 

The basic issue here is one of cost of backup hardware vs. cost of lost training 
time for a system which has many single points of failures All time cntica computer 
systems (like banks, communications systems, military systems with 24 h °ur per day 
365 days per year requirements) have backups to minimize down time. Given fixed 
launch dates for SS crews, and critical training schedules, having a no single point of 
failure in the SCS/PTC training system could well be a needed system requirement. 

The hardware implications of no single point of failure are fairly straight forward 
- there is a backup hardware for every piece of SCS hardware. The software issues 
are a bit more complex: What is the fail over time? Is there a i^renront to tamtam 
some history data as part of fail over? How much history must be kept. Now t0 
synchronize after fail over? If failure occurs while messages are on the line, how do 
you decide if they need to be retransmitted? 

A different approach would be to specify availability, reliability, MTTR. and 
MTBF requirements for the SCS. This might prove to be a more cost effective method 
of minimizing lost crew training time. 
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Operations Evaluations Viewpoint 

The operations evaluation function imposes no unique requirements in the area 
of the definition of no single point of failure. 

Recommendations 

o Study required. Related to the A-3 study of other simulators we will 
investigate their availability and time to recovery requirements. This will be the 
approach to writing SCS failure requirements, i.e. there will be a requirement for 
system availability, and a requirement for recovery time. There are some systems that 
are operational that can be used to obtain achievable and needed availability 
requirements 


Related Issues; A-3, A-2 
Open Issues/Notes 
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SCS Issue Identification 

Issue Title: Requirements for Interfaces with SSIS and SOAN 

Issue No: A-12 Report Version: 2 

Scope of Potential Reauiremfi Dl 

The scope of this issue ranges from having no interface with SSIS (Space Station 
Information System) and SOAN (Science Operation and Analysis Network), to being 
able to send simulated experiment data from the SCS to the SSIS and SOAN. 


Assumptions 

38. The current assumption is that all interfaces to SSIS and SOAN will be through 
the POIC. Thus, the SCS need only worry about the proper interface to the POIC, and 
the POIC will solve further external interface problems. 

Brief summary and rationale 

Training Viewpoint 

The only impact this issue has from the training viewpoint is if the PTC has the 
responsibility to provide training for either crew or ground operations personnel in 
operational functions that are unique to the SSIS or SOAN interface. 

SCS Development Viewpoint 

Having an interface to SSIS and SOAN will increase the size and complexity of 
the SCS software. It might also have some effect on the SCS hardware, depending 
on what is required to interface with SSIS and SOAN. 

Operations Evaluations Viewpoint 

Operations evaluation usage of the PTC is expected to be conducted locally at 
MSFC. Therefore, the operations evaluation function imposes no unique 
requirements for interfaces with SOAN and SSIS except for the POIC interface 
discussed in other issues. 

Recommendations 

o No study required. 

Requirement - The SCS shall interface with and be fully capable of using the 
SSIS network. 
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Open Issues/Notes 

This has implications on the actual design of the SCS. but may not have much 
of an effect on a top level concept definition. 
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SCS Issue Identification 

Issue Title: Requirements for Configuration Management of Simulation 

Software 

Issue No: A-13 Report Version: 3 


Scope of Potential Requirement 

The scope of this issue ranges from having minimal configuration management 
of simulation software to having full and complete configuration management of the 
simulation software, just like will be done for the flight software. 


Assumptions 

Brief summary and rationale 


Training Viewpoint 

Configuration management is perhaps one of the most critical issues from the 
training viewpoint. It is necessary that the training programs will have to be repeated 
many times for different crews and operations personnel. An adequate configuration 
management system is imperative so that the training conductors will always know 
what version of a simulator is available to them to use for each particular training 
exercise. To be effective the configuration management system should be largely 
transparent to the users of the system. 


SCS Development Viewpoint 

If SSE is utilized to a large extent, there are enough tools for configuration 
management (CM), that not much other effort will likely be needed in the CM area for 
SCS If SCS does not utilize SSE as much, then some attention must be paid to 
developing a cost effective CM plan. Whatever tools are used, a sound, basic CM plan 
and set of tools must be part of the SCS/PTC system to reduce to near zero training 

time lost to CM problems. 


An ideal CM system would automate much of the work and provide traceability 
such that it would be easy to see, when something changed, what other items would 
be affected. 


Operations Evaluations Viewpoint 

The operations evaluation function imposes no unique requirements for 
configuration management of simulation software. 


Recommendations 
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o Study required. Configuration of the computer hardware and displays will be 
accomplished operationally, as is done at most computer facilities. We will look at the 
SSE tools, and write requirements based on the tools, and experience with the PCTC. 

Related Issues : A-1 

Open Issues/Notes 

For the PTC, there is the issue of hardware CM to control the configuration of 
the panels, switches, etc. 
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SCS Issue Identification 

Issue Title: Definition of GSE-Provided Services 

Issue No: A-14 Report Version: 2 


Scope of Potential Requirement 

The scope of this issue is for all training to be done with simulators, i.e. no GSE 
provided services, to provisions for all payload related SS services. 

Assumptions 

35. The SCS will support payload flight hardware, i.e. the SCS will have the 
hardware, software, hooks, and scars to support flight equivalent payload hardware. 

Brief summary and rationale 

Training Viewpoint 

From the training viewpoint this issue is basically the same as issue A-5. 

SCS Development Viewpoint 

Flight equivalent experiment hardware will require the SCS to be able to 
provide a relatively full set of SS services. Spacelab PCU/ATE experience indicates a 
significant impact on potential SCS functional requirements. These types of interfaces 
will increase the cost of both SCS hardware and software. The best thing that can be 
done to reduce costs is to identify requirements for these types of services as early in 
the development cycle as possible. 

Operations Evaluations Viewpoint 

Some GSE-provided services (e.g. power, thermal, fluids) may be required for 
some operations evaluation functions involving flight-like or prototype experiments. 
However, these are the same GSE requirements that are imposed for the use of flight 
equivalent hardware for training. Further evaluations should be performed to define 
firm requirements in this area. 

Recommendations 

o Study required. We will determine and categorize the types of services 
needed by the envisioned payload manifest. This will allow us to assess the impact on 
SCS, and write the appropriate requirements for SCS to support this. 


Related Issues : A-5, A-10 
Open Issues/Notes 
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SCS Study Issues Assumptions 

1 . Primary responsibility of the PTC is to provide payload operations training 
including both nominal and contingency operations for flight and ground personnel. 

2. Payload operations training will include experiment training, payload unique 
operations support systems training , and payload unique subsystems training. 

3. The PTC/SCS will support all manned payload training for all payloads, 
including US Lab, Attached Payloads, ESA, and JEM. 

4. ESC training is assumed to not be a responsibility of the PTC. No unique 
interface between the ESC and the SCS is required, nor will the SCS simulators 
require any unique capabilities related to ESC training. The only support of the SCS 
to ESC training will be via the POIC during consolidated and/or integrated simulations. 

5. Any PTC interfaces to UOFs, DOCs, or ROCs will be through the POIC. There 
will not be any direct data interfaces from the PTC to the UOFs, DOCs, or ROCs. 

6. The POIC can support the processing of real time or simulated data streams 
simultaneously. This means the POIC can support training using simulated data from 
the PTC simultaneous with on going real time operations. 

7. The OMS software functions will be provided as part of the DMS Kits. Therefore 
no special simulator development will be required for OMS training. 

8. The PTC will not be responsible for any subsystems training. However, the PTC 
will utilize minimum subsystem interfaces as necessary to support payload training. 

9. All software subsystem simulators utilized in the PTC will be provided by work 
package contractors via the SSE. Modifications of these will be required. 

10. PTC experiment simulators will only provide high fidelity simulation of the 
housekeeping data. Experiment science data will not be dynamically simulated. 

1 1 . For loading purposes, all simulations are assume to be done via software. 
However, the PTC/SCS is assumed to have the hooks and scars to support flight 
equivalent hardware and software when it is available. 

12. The PTC will utilize DMS Kits that are provided by JSC/WP02. 

13. The PTC will provide for the generation of all experiment data stream formats 
including dedicated experiment channel data streams. However, the data to fill 
dedicated experiment data streams will not be dynamic. 

14. All data on the payload bus will be simulated at the PTC. The payload bus 
includes two nodes with 10 megabits of data on each node. The PTC shall also output 
the data from the systems bus which also contains 10 megabits. 
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15. Experiment prototype systems will be able to interface to the PTC data stream 
generator to provide dedicated experiment channel data. 

16. ECWS simulators will be provided by WP01 contractor. 

17 The PTC will be required to support full consolidated experiment operations 
training on 3 SS increment configurations simultaneously (2 U.S. Labs and 1 
ESA/JEM) with part task training on individual experiments from 3 other increments 
(each of the 3 roughly equal to 1/3 of the U.S. Lab in capability). 

18. Development and verification efforts must be able to proceed simultaneously 
with training. 

19 For purposes of this study, training and development are assumed to be 
accomplished on a 40 hours per week day shift basis, with other hours reserved for 
backup, PM, and overflow work.. 

20. A backup interface capability will be required between the PTC and the SSTF in 
order to execute payload simulators in the PTC in support of integrated simulations at 
the SSTF in some cases where it is not feasible to transport the payload simulator to 

the SSTF. 

21 Training done via remote execution is done on the SCS, or the trainees come to 
MSFC and train here. Thus, the computing load would be the same, and will be 
accounted for in the study. 

22. No SCS simulation of EVA or SCS production of other rendered outside attached 
payload pictures. 

23 The standard update rate (required to support realistic displays for the trainees 
in the PTC) for the SCS for dynamic data will be once per second. A subset of the 
simulator tasks (required to support realistic input by the trainees) will be required to 
execute at up to 10 Hz rate (e.g. response to hand controller inputs). A rate of 25 Hz 
may be required for pointing systems. 

24. To work with the core subsystem flight equivalent hardware and software, the 
SCS must work at rates that satisfy this flight equivalent hardware and software. 

25. Onboard data storage capability of the DMS will be part of the DMS simulation 
capability provided by JSC/WP02. 

26. Virtual instruments are acceptable in the part task experiment simulation 
workstations, but may not be good enough for use in the consolidated increment 
training environment. 

27. There are currently no requirements for onboard training levied on the SCS. 

28. SCS will use SSE capabilities for software development and maintenance. 
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29. For purposes of loading for the SCS study, all simulations are assumed to be 
built, integrated, tested, and maintained on the PTC/SCS. Sizing must be done for 
worst case. 

30. Late changes to the simulators are a problem that the PTC/SCS people have to 
solve. 

31 . Recent top level agreements that the crew will train together at JSC the final 
period before launch dictate that the SCS simulations will be transportable to the 
SSTF. 

32. The PTC/SCS people at MSFC will be responsible for maintenance of the 
payload simulators, including the period when the simulators are used at the SSTF. 

33. Integration of the payload simulators into the SSTF will be through a 
JSC/MSFC agreed upon method. 

34. There must be a capability to simulate payloads, if only for simulator 
maintenance, at the PTC/SCS for the duration of the payload's mission life. Thus, if a 
payload simulator is both hardware and software, the hardware may be duplicated, 
virtual panels may be used, or a parallel software simulator may be developed in order 
to retain the payload simulation capability at the PTC/SCS. The duplicate/substitute 
simulator may be employed at JSC in place of the original hardware/software 
simulator at the PTC. 

35. The SCS will support payload flight hardware, i.e. the SCS will have the 
hardware, software, hooks, and scars to support flight equivalent payload hardware. 

36. Assume the Space Station life cycle is 30 years, but that computers, displays, 
and other COTS electronic equipment will have to be replaced or upgraded at 
intervals ranging from 5 to 10 years. 

37. A host-based DMS functional simulation (FSIM) to be provided by SSE will 
NOT run in real time. Thus, FSIM is assumed to be of minimal utility in the SCS. 

38. The current assumption is that all interfaces to SSIS and SOAN will be through 
the POIC. Thus, the SCS need only worry about the proper interface to the POIC, and 
the POIC will solve further external interface problems. 



